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Typical  “Estimating”  Problems 

“My  manager  would  not  approve  the  initial  estimate” 

“The  project  doubled  in  size  after  the  estimate.” 

“The  new  CASE  tool  did  not  work  correctly  and  slowed  us 
down.” 

“We  had  no  estimating  tool  at  the  time  of  the  estimate.” 

“I  lost  some  developers  and  had  to  find  replacements.” 

“Some  people  were  assigned  to  the  project  charge  number 
before  the  work  started.” 
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Budgeting 

Budgeting  is  different  from  estimating 

Budget  determines  a  value  proposition. 

•  I  want  to  build  my  own  house  on  a  piece  of  land  I  own. 

•  I  can  afford  to  invest  $300,000  in  this  house. 

•  I  can  make  tradeoffs  in  the  requirements  to  achieve  this 
number. 

Preliminary  estimate 

•  I  know  the  cost-basis  of  a  house,  similar  to  one  I  want, 
was  $150/sq-foot.  Since  my  budget  is  $300K.  I  should 
plan  a  house  that  is  a  bit  less  than  2000  sq-feet. 

The  budget  can  come  before  the  requirements. 

•  My  house  needs  3  bedrooms  and  an  art  studio. 
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The  Estimate  is  Not  the  Plan 

The  estimate  describes 

•  What  it  will  cost  in  terms  of  how  much  work  is  required 

•  How  long  it  will  take  for  the  assigned  number  of  people. 

•  A  curve  that  shows  the  relationship  between  people  and 
time 

•  Which  inputs  and  assumptions  had  the  greatest  effect 
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Multiple  Purposes 

Development  of  budgets 

Project  planning 

Project  change  management 

Bidding  on  an  RFP 
Preparation  of  an  RFP 
Strategic  planning 
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Outline 

Purpose  of  an  estimate 
Create  a  standard  for  estimates 
Estimating  inputs 

Process  factors  for  good  estimating 
Risk  factors  in  estimating 
Wrap  up 
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Begin  with  the  End  in  Mind* 

How  does  the  estimate  affect  the  actions  and  decisions  of 


Principle:  It’s  easier  to  make  a  process  or  procedure  stick  if 
it  serves  several  different  people. 

Steven  Covey,  Seven  Habits  of  Highly  Effective  People 
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Estimation  Process  Serves 


Project  Manager 

Must  plan  and  control 
the  project. 

Re-plan  when  there  are 
changes. 


Estimator 

Trained  to  the  process. 
Access  to  project  history 


Senior  Manager 

Allocate  resources 
Reprioritize  work 
Trusts  the  estimate. 


VS 


Project  Team 

Check  assumptions 
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Project  Manager 

Role:  Has  the  direct  responsibility  for  project  success. 

Uses  the  estimate  for  planning 

-  Scoping,  tasking,  staffing,  scheduling,  constraints, 
risk  planning 

Uses  the  estimate  to  help  with  change  management 

-  Why  is  the  estimate  now  inadequate? 

-  Additional  knowledge  acquired  during  project 

-  Complexity,  resources,  process  capability  &  capacity,  etc. 

-  Changed  constraints 

-  Changed  scope 

-  Risk  event 
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Executive 

Role:  Allocate  resources  and  working  capital  according  to 
business  priorities. 

Uses  the  estimate  to: 

•  Assess  affordability,  cost  /  benefit 

•  Prioritize  work  among  competing  projects 

•  Schedule  and  allocate  resources  and  working  capital 

•  Respond  to  change  requests  by 

-  Reprioritize  and  reschedule  projects,  and/or 

-  Reallocate  resources 
Estimating  Needs: 

-  Costs,  resources,  duration,  risk  and  possible  tradeoffs 
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Estimator 

Role:  Accountable  for  making  estimate,  training  others  to 
estimate. 

Identifies  critical  project  factors  that  drive  the  estimate. 
Uses  historical  estimates  and  project  data 

-  Formulate  current  estimate 

-  Improve  estimating  process  and  methods 

-  Identify  and  modify  adjustment  factors 

-  Identify  constraints 

-  Validate  estimating  models 

-  Post  project  reviews  to  understand  influencing  factors 
Values:  accuracy,  productivity,  professional  growth 
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Constraints 

-  Cost,  Schedule 

-  Resource  limits 

-  Other 
Directives 

-  policy,  publication 


Scoping 

-  Deliverables 

-  Requirements 

-  Complexity 

-  Lifecycle 


Estimating 


Resources 

-  Skilled  people 

-  Tools,  methods 

-  Project  history 


©  2004  by  Carnegie  Mellon  University 


Estimating 

Context 


Estimate 

-  Size,  defects,  costs, 
duration,  staffing 

-  Documented  inputs , 
assumptions 

-  Estimating  method 

-  Comparable  projects 

-  Sensitivity  analysis 
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Estimating  Process  Outputs 

Purpose  of  the  Estimate 

Those  things  with  numbers  that  we  can  get: 

•  Total  and  external  costs, 

•  Duration, 

•  Workforce  size  and  buildup 

•  Size, 

•  Defects, 

•  Productivity. 

Assumptions  and  constraints  considered 
Project  Lifecycle 

Estimating  method,  tools  utilized,  comparable  projects 
Person  who  did  the  estimate 
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Outline 

Purpose  of  an  estimate 
Create  a  standard  for  estimates 
/  Estimating  inputs 
Process  factors  for  good  estimating 
Risk  factors  in  estimating 
Wrap  up 
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Constraints 

-  Cost,  Schedule 

-  Resource  limits 

-  Other 
Directives 

-  policy,  publication 


Resources 

-  Skilled  people 

-  Tools,  methods 

-  Project  history 
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Context 


Estimate 

-  Size,  defects,  costs, 
duration,  staffing 

-  Documented  inputs, 
assumptions 

-  Estimating  method 

-  Comparable  projects 

-  Sensitivity  analysis 
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Scoping  Data 

Scope  Elements 
•  Size 

Project  Lifecycle 
Complexity  factors 

Where  do  you  get  this  data? 
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Defining  Scope 

Why  are  we  doing  this  project? 

What  objectives  should  the  project  accomplish? 
What  are  we  responsible  to  deliver? 

-  Software 

-  Documentation 

-  Hardware  and  other  deliverables 

-  Demonstration  and  marketing  events 

-  Installation  and  deployment  services 

-  Formal  external  reviews 
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Size  the  Scope 

From  the  list  deliverables, 

•  Identify  required  configuration  items 

•  Classify  as  needed  (e.g.  new,  reuse,  environment) 

•  Size  items  and  identify  uncertainty  ranges  for  size 


Do  you  need  size  for 

every  single  configuration  item? 

No,  but  I’d  suggest  requirements,  code,  test  cases  and 
any  externally  delivered  documentation. 
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Lifecycle  Inputs 

Release  Planning  from  Product  Management 

•  Requirements  and  release  content 

•  Customer  and  market  data 

•  T  radeoff  goals 

Product  development  lifecycle 

•  Phasing 

•  Standard  intermediate  deliverables 

•  Tailoring  information 

•  Transition  to  manufacturing  and  deployment 
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Complexity  Factors 


Technical  complexity  factors 
New  aspects  of  business  domain 
Organization  and  geography 
Certain  constraints  coming  from  the  customer 

•  Dates 

•  Customer  environment 


Complexity  factors  increase  risk  or  uncertainty. 
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Scoping 

-  Deliverables 

-  Requirements 

-  Complexity 

-  Lifecycle 


Constraints 

-  Cost,  Schedule 

-  Resource  limits 

-  Other 
Directives 

-  policy,  publication 
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Estimating 

Context 


Estimate 

-  Size,  defects,  costs, 
duration,  staffing 

-  Documented  inputs, 
assumptions 

-  Estimating  method 

-  Comparable  projects 

-  Sensitivity  analysis 
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Constraints  and  Directives 

Constraints 

•  Budget  and  schedule  constraints  and  tradeoffs 

•  Resource  limits 

-  Restricted  availability  of  people,  facilities,  etc. 
Directives 

•  Purpose  of  the  estimate 

•  General  policy  about  projects  and  estimation 

•  What  to  include  for  publication 

•  Additional  requirements  or  changes  for  internal  use 

Directives  may  be  “messages”  to  the  project  manager. 

•  Use  Tom’s  lab  for  testing. 

•  We  have  to  bring  this  project  in  within  15  months. 

•  The  point  is  to  record  these  directives  with  assumptions. 
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Resources 


People  and  skills 

•  Estimate  will  depend  on  availability  of  skilled  people  to 
perform  the  project  work. 

•  New  hires  will  extend  the  project  duration  and  increase 
costs. 

Tools  and  methods 

•  If  tools  and  methods  for  the  project  are  not  stable,  then 
extra  time  will  be  required  for  learning. 

Project  history  database 

•  Data  about  team  productivity 

•  Information  about  complexity  factors 

•  Information  about  risk 
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Outline 

Purpose  of  an  estimate 
Create  a  standard  for  estimates 
Estimating  inputs 

Process  factors  for  good  estimating 
Risk  factors  in  estimating 
Wrap  up 
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Estimating  Process  Steps 

1 .  Define  the  scope 

2.  Technical  analysis 

3.  Business  analysis  (optional) 

4.  Follow-through 


1 .  Park,  Robert,  “Checklists  and  Criteria  for  Evaluating  the  Cost  and  Schedule 
Estimating  Capabilities  of  Software  Organizations,”  SEI-95-SR-005 
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Technical  Analysis 


Modeling 

•  Document  inputs  and  derivation  of  inputs. 

•  Document  comparable  projects  and  rationale. 

Adjust  Estimate 

•  Accounting  for  factors  not  addressed  by  the  model. 

•  Eliminating  model  activities  and  elements  that  do  not 
apply. 

•  Project  staffing  profile  requirements  rate  adjustments. 

Create  auditable  documentation  and  rationale  for  each 
adjustment. 
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Business  Analysis 

Adjust  estimate  to  proposal  or  bid. 

•  “Bid-to-win” 

•  Cost-plus 

•  Incentive  contract 

-  Pays  more  for  early  completion 

-  Pays  incentive  for  reduced  cost 
Risk  assessment 

•  Risk  assessments. 

•  Risk  graphs. 

•  Bid  memorandum  with  parameter-by-parameter 
explanation  of  the  risks. 
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Follow-Through 

Estimate  to  Complete 

•  Updated  size  estimates. 

•  Updated  reuse  estimates. 

•  Updated  parameter  values  and  rationales  for  changes. 

•  Revised  project  estimate. 

•  Cost  to  complete. 

•  Schedule  to  complete. 

Post-Project  Review  and  Data  Collection 

•  Resulting  size,  reuse,  and  environmental  values 

•  An  analysis  of  differences  between  results  and  estimate. 

•  Updated  and  recalibrated  cost  model  database. 

•  Lessons  learned. 
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The  Estimate  is  Not  the  Plan 

The  estimate  describes 

•  What  it  will  cost  in  terms  of  how  much  work  is  required 

•  How  long  it  will  take  for  the  assigned  number  of  people. 

•  A  curve  that  shows  the  relationship  between  people  and 
time 

•  Which  inputs  and  assumptions  had  the  greatest  effect 
How  do  you  plan? 
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Mapping  the  Estimate  to  the  Plan 

The  WBS  was  chosen  as  part  of  the  estimating  process. 
3-step  allocation  method 

•  Allocate  costs  to  deliverables  (supports  earned  value). 

•  [Allocate  defect  information  to  deliverables] 

•  Allocate  schedule  to  milestones. 

•  Map  people-skills  to  tasks. 

You  may  need  to  iterate  through  the  steps  in  order  to  build 
a  schedule. 

Create  baseline  plan  and  charts  that  map  estimated  values 
to  schedule  for  reporting. 
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Estimating  Process  Quality  Objectives 

Organization  has  confidence  in  accuracy  of  the  estimate. 
Organization  provides  clear  policy  on  when  to  estimate. 
Staff  know  who  provides  the  estimate  and  expertise. 

Staff  know  what  the  estimate  contains  and  how  to  use  it. 
The  estimate  is  provided  in  a  familiar  format. 
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6  Requisites  for  Reliable  Estimating  Processes 

•  A  corporate  memory  (database,  repository) 

•  Structured  processes  for  estimating  size  and  reuse 

•  Mechanisms  for  extracting  history  from  projects 

•  Audit  trails  (values  used  to  estimate  are  recorded) 

•  Integrity  in  dealing  with  cost  and  schedule  constraints 

•  Data  collection  and  feedback  processes  that  foster 
capturing  and  interpreting  data  from  work  performed 


Park,  Robert  E.,  “Checklists  and  Criteria  for  Evaluating  the  Cost  and 
Schedule  Estimating  Capabilities  of  Software  Organizations”, 


SEI-95-SR-005 
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7  Indicators  of  Estimating  Capability 

Management  acknowledges  its  responsibility  for  developing 
and  sustaining  an  estimating  capability. 

The  estimating  function  is  supported  by  budget. 

Estimators  are  equipped  with  tools  and  training  needed  for 
reliable  estimating. 

People  assigned  as  estimators  are  experienced  and 
capable. 

Recognition  and  career  paths  exist  such  that  qualified 
people  want  to  serve  as  estimators. 

Process  improvement  resources  and  funds  are  committed 
to  improving  the  estimating  process. 

The  estimating  capability  of  the  organization  is  tracked  and 
evaluated. 

Park,  op.  cit. 
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Organizational  Behaviors 

Estimators  have  experience  at  estimation  as  it  applies  to 

•  Business  domain, 

•  Project  life  cycle, 

•  Capabilities 

•  And  our  other  processes  (budgeting,  etc.) 

Project  managers  know  the  people  who  estimate  and  trust 
them. 

Managers  believe  the  estimates  and  act  accordingly. 

•  Resource  allocation  follows  the  estimate. 

•  Work  can  be  reprioritized  based  on  the  estimates. 
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Historical  Database 

Integral  to  the  estimating  process. 

Estimators  have  an  active  role  in  specifying  and  sustaining 
the  estimating  history. 

Database  contains  a  useful  set  of  completed  projects. 

Any  excluded  data  is  clearly  identified. 


Environ 

ment 


Product 


Project 


Devel. 

Team 


Future 

/ — - 

Projects 

v-J 

History 

Database 
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Project  Management  Metrics 


Milestone 

Plan-date 

Actual-date 

Plan-cost 
to  date 

Actual-cost 
to  date 

Req.  Accept. 

1/31/04 

2/12/04 

(Effort  or  $$) 

Project  Plan 
Approval 

1/15/04 

1/22/04 

CDR 

4/30/04 

Sample  table  for  diagram  on  previous  slide 
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Project  Product  Metrics 


Item 

Estimated 

Actual 

Unit 

Code-Size 

100 

113 

KLOC 

Design- 

Defect 

400 

373 

Count 

Test-Defect 

2000 

2211 

Count 

User-Doc 

300 

245 

Pages 

Sample  table  for  diagram  on  previous  slide 
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Parametric  Estimating  Process 
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Estimate  more  than  once? 

A  Product  Development  Life  Cycle 


Product 

Planning 

Specification 

Design  &  Code 

Test 

\  / 

\ 

4 

\ 

Estimate  #1  Estimate  #2  Estimate  #3 


Why  would  you  do  this? 
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The  Estimating  Role 

Estimators  can  take  responsibility  for  many  estimating 
chores. 


Development  of  budgets 

Project  planning 

Project  change  management 

Bidding  on  an  RFP 
Preparation  of  an  RFP 

Strategic  planning 
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The  CMMI  Says: 

Estimating  appears  in 
Project  Planning 

•  SG  1  Estimates  of  project  planning  parameters  are 
established  and  maintained. 

-  Project  planning  parameters  include  all  information 
needed  by  the  project  to  perform  the  necessary 
planning,  organizing,  staffing,  directing,  coordination, 
reporting  and  budgeting. 

And  is  supported  by  the  Generic  Goals 
(specifically  GG2  and  GG3) 
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CMMI  Generic  Goals 

GG2:  Institutionalize  a  Managed  Process 

•  Establish  an  organizational  policy 

•  Plan  the  process 

•  Provide  resources 

•  Assign  responsibility 

•  Train  people 

•  Manage  configurations 

•  Identify  and  involve  relevant  stakeholders 

•  Monitor  and  control  the  process 

•  Objectively  evaluate  adherence 

•  Review  status  with  higher  level  management 
GG3:  Institutionalize  a  Defined  Process 

•  Collect  improvement  information 
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Sample  Estimating  Policy 

•  Process: 

Product  development  projects  will  use  “SP10:  Project 
Estimate”  to  provide  needed  data  to  the  work  plan. 

•  When: 

The  Project  Estimate  will  be  created  within  5  days  of 
acceptance  of  requirements  (ref.  SP1 :  Requirements). 

•  Who: 

Project  Estimate  will  be  prepared  by  a  staff  member  who 
has  completed  Estimating  Training  and  has  participated  in 
estimating  at  least  one  other  project. 

•  Review: 

Satisfactory  performance  of  Project  Estimate  will  be 
assessed  at  Annual  Product  Development  Quality  Review 
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Outline 

Purpose  of  an  estimate 
Create  a  standard  for  estimates 
Estimating  inputs 

Process  factors  for  good  estimating 
Risk  factors  in  estimating 
Wrap  up 
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Product  Management 


Is  this  a  one-time  build? 

•  Have  to  have  all  the  requirements  at  once. 

•  Customer  may  “gold-plate”  the  request. 

•  Little  development  time  to  learn  the  customer 
domain 


Higher 


Or  multiple  releases?  Lower 

•  Negotiate  features  by  release.  Risk 

•  Provides  time  to  learn  about  customer  domain. 


Risk  mitigation: 

•  Two  estimates  -  budget  and  after  specification 

•  Double  the  time  allocated  for  requirements  analysis 
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Maintenance  or  Development? 


Development  never  ends 
Same  team  does  maintenance  and  development 
Same  cost  account  used  for  maintenance 
Project  leader  and  technical  leader  are  the  same 

Planned  release  schedules  for  development  projects 
Professional  project  management 
Separate  cost  accounts 


Higher 


Lower 


This? 


Development 

Maintenance  and  Enhancement 

M  TUT 

ttt  rr  3  )  ■ 

2/1/2004  3/1/2004  4/1/2004  5/1/2004  6/1/2004  7/1/2004  8/1/2004  9/1/2004  10/1/2004  11/1/2004 

Jan -04  Nov -04 


Or  this? 


Development 

Dev.  2 

Dev.  3 

Maintenance 
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History  Database  Risks 


“Every  project  is  different.” 

Organization  has  no  set  milestones. 

Only  code  and  test  have  history. 

Database  contains  no  similar  project. 

Project  history  is  collected  long  after  project. 


Common  set  of  milestones  is  in  history  database. 
Small  set  of  WBSs  are  available  and  every  project  is 
tailored  from  one  of  these. 

History  database  has  similar  projects. 

Project  history  is  recorded  as  project  milestones  and 
deliverables  are  completed. 


Higher 


Lower 
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People  Risks 


Everyone  estimates  his  own  project. 

Estimating  is  not  part  of  every  project. 

Limited  access  to  historical  data. 

Estimator  has  limited  experience. 

Estimator  has  limited  access  to  other  estimators. 


Estimator  role  is  an  official,  recognized  one. 
Estimator  has  access  to  other  estimators. 
Estimator  understands  business  domain. 
Estimator  has  full  access  to  past  projects. 
Estimator  has  training  and  experience. 


Higher 


Lower 
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Principles  of  Estimating 

Estimates  are  made  by  people,  not  by  models. 

•  They  require  reasoned  judgments  and  commitments  to 
organizational  goals  that  cannot  be  delegated  to  any 
automated  process. 

All  estimates  are  based  on  comparisons. 

•  When  people  estimate,  they  evaluate  how  something  is 
like,  and  how  it  is  unlike,  things  that  they  or  others  have 
seen  before. 

Before  people  can  estimate,  they  must  acquire  knowledge. 

•  They  must  collect  and  quantify  information  from  other 
projects,  so  that  they  can  place  their  comparative 
evaluations  on  demonstrably  sound  footings. 

Park,  Reference  3 
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